昨天，我們提到了產品開發的核心，大家心裡雖然都知道是「以人為本」，但實際上卻很難做到，在產品設計以及開發的過程中，都很容易是牽一髮動全身，或是多半開發進程是為了追債，排程光維護、調整都來不及了，不一定有餘裕再多做什麼。

所以雖然了解使用者很重要，但尷尬的是，反而如果你去特地「了解使用者」，很容易被大家覺得是沒事找事情做，這件事情很難變成有價值的投資。當然，這並不代表所有產品都沒有在迭代、測試，但很顯然，要能夠開始做到這件事情，通常確實要有些資源、資本，就算「以人為本」確實很重要，不過在傳統數位產品上的實踐往往會遭遇到許多挑戰。

舉例來說，我們常常嘴上說的「迭代」，如果要在傳統 App 開發上實現這件事，會經歷過哪些事情呢？

1. 有個熱心的 PM 推動了使用者測試以及深度的訪談，收斂出一些對於 App 邏輯上有機會有顯著幫助的觀點，在週一早上他邀請了大家參加這個會議、提出了這個改動的想法
2. 在會議當中，這個熱心的 PM 將自己想法的來龍去脈解釋的非常詳細，大家腦筋都動得很快、開始討論實際上實踐功能的細節，充滿著歡快的氣氛。
3. 這個時候技術主管補充：「不過這個功能如果要結合現有的功能，可能還得要考慮到原先的架構能不能順利整合在一起，大概需要 4 週的時間」大家還沈浸在歡快的氣氛之中，這句話自然是只放了一點點在心上。
4. 接下來 4 週開發團隊都排程進 sprint 中，埋頭苦幹、都沒有打混摸魚，為了這個新功能加班，因為需要跟既有的功能做整合，他們也不得不去重構一部份的程式碼，就在這個過程中，一些隱隱約約的蝴蝶效應發生了。
5. 在實際測試的時候，有一些意想不到的 bug 冒出來了，團隊也得額外花費其他的時間來解決因為新功能的問題，這件事情讓時程又多了 2 週，開發團隊多開了一些會跟 PM 解釋延期的原因、PM 向上呈報主管階級，被小小的教訓了一頓，又指點一些改進 App 的方向。
6. 經過主管指點的方向，又有一些小部分需要微調，這個微調又牽動到了某些小地方，開發團隊只好再多加點班，期待再過個 2 週可以完成。
7. 經過了許多紅牛與堅持，功能順利在經過 8 週後上線，終於可以去解一些這 8 週來自於其他客戶或使用者的反饋或修正。
8. 新版本發佈之後，使用者很喜歡！太好了！但在喜歡新功能的同時，也有一些人抱怨 App 變慢了，很卡，PM 不得不再去一一釐清手機機型、版本來做測試。
9. 看來，又要優化性能跟調整一些發現的問題，又再經過了 4 週，大家看 PM 的眼神，已經悄悄地產生了一些變化

技術主管拍拍 PM 的肩，偷偷耳語：「打工人何苦為難打工人……」

光做一個新功能，在傳統的應用程式中可能就要歷經這些，時間已經過了三個月，因為軟體分層的結構、資料庫每層的變動可能都會影響其他層，這是需要工夫去仔細協調的，在組件上如果有聯動也容易牽一髮動全身，舊有的程式碼的結構可能很難去修改，還不知道會不會踩到遺存萬年的技術債地雷。這涉及到太多層面：技術架構、開發流程、開發習慣、協作、內部與外部的壓力….

甚至如果有些規模比較大的功能的加入，我們可能會選擇的作法會是拼裝車，無論是技術上或是產品本身，或許會傾向在原先的產品上直接像是加外掛一樣，不斷加掛上去，照這個推論繼續下去，最後這個 App 就會變成一個 Super App，先撇開技術的層面不論，一個 Super App 會加深使用者的認知負擔，干擾變多、流程更複雜，這導致學習的曲線變長或是讓舊有的使用者很難適應，雖然功能加上去了，解決了更多問題；但另一個層面，這些日漸膨脹的功能導致使用者的認知的成本變高，技術債也越來越深，萬劫不復......

幹！這個以人為本的世界就是這樣崩塌的！

我們認為，AI Agent 作為一個產品在無論是開發上、或是使用者體驗，能夠改善前述提到的狀況，讓我們更有餘裕回到產品的本質跟初衷，更能關注使用者的需求本身。

這是為什麼呢？

講個有趣的例子，今天我們要開發一個賣演唱會票的平台，要怎麼做？

要開發一個票務平台，我們會需要訂票流程、座位選擇、我們會需要金流、帳號管理、處理訂票請求、庫存，尤其是在同時處理大量請求時，還得下功夫去應對在每次搶票時瞬間的高負載、更新座位的庫存、管理每個座位的狀態……有不少事情需要做，但都可以想像得到。

但如果這時候你發現：讓票能夠在被購買後，依照市場機制重新分配每張票的價值，讓票能夠自由地交易，在這個交易的過程中去抽水，這件事情對使用者來說很有需求（不鼓勵黃牛票，但用這個舉例比較快）。

如果這個時候需要加上這個新的機制或者系統在原先的票務平台上，要怎麼做呢？

這個過程想必會涉及非常大量的程式碼修改以及新功能的開發，像是一定會需要一系列新的介面，背後牽涉到許多票的轉移機制、驗證、API的擴展等等……有更多的事情需要做，這些需要做的事情，對於開發團隊而言，多到不一定符合成本效益，因為只要稍微評估一下，這件事情背後指涉的是許多複雜的工。

如果是交給 AI Agent 來完成「票務與轉讓」的需求呢？

首先，若是 AI Agent 主要透過對話介面來完成使用者的目標，那麼就會先節省了許多 GUI 的設計與開發的成本；傳統在開發軟體時，我們需要為每個功能與流程都設計專門的頁面，並且也得考量到使用者如何學習使用這些介面，很多的時間來去討論以及讓使用流程更順暢。

在核心系統來說，比起傳統要不斷更新固化的系統，讓系統能夠符合更多需求的規則，AI Agent 主要需要關注的是拓展 Agent 本身的對話能力與後端邏輯，至少能夠更關注在更新模型本身的知識庫，簡化整體的系統架構、降低更動的複雜度。

甚至如果以更細節的功能，例如推薦功能來說，傳統的做法需要開發非常複雜的算法，而如果以 AI 模型來協助這件事情來說，模型本身可以不斷地、動態地學習，調整推薦的策略；而客服功能呢？AI 有機會就直接處理掉大部分的詢問、最大化地減少使用額外的人力來協助處理使用者的問題。

重點是，AI Agent 的價值不是節省時間，他不是一個更有效率的工具而已，AI Agent 作為產品的價值是一個思維轉變的可能，從原本的產品本位思考、因為有了餘裕因此能夠轉向真正的「以人為本」。

如果讓我們擁有更多餘裕，我們剩下的時間會花在哪裡？當然，我們就能有更多的時間將重心聚焦到更根本的、產品的本質上：使用者的需求，只要能夠創造出餘裕，我們就有更多的時間去深入地理解使用者，敏捷也不再只是流程，我們能更快速地去反映市場的需求，讓產品思維的體現，更比起傳統的軟體開發模式更多。

只能說：好期待這一切。